No; this misses the point. I don't like this method's existence; it's too tempting to use it when usually you shouldn't use it.

Could you elaborate more on what the problem with this method is? Is there a more general approach that we are supposed to take for getting clients? at least to me, it appears super useful... If we we have a client created, great, use it, and if not, it creates it...

Only six classes call it, so if we want to eliminate it, it doesn't seem unsurmountable. Just unclear on what we would replace it with.

If the javadocs don't already answer your question, I failed to make them clear enough. Let me flip this inquiry around... hey Eric, why do you think we need a cache of clients at all? Why cache them? What's wrong with our existing clients (linked to in javadocs)?

note: distributed file store usage could easily switch to coreContainer.getDefaultHttpSolrClient().requestWithBaseUrl

okay, after re-reading and more context.. ( I sound like a LLM!) I think what you are saying is that we could replace most calls with one of:

   * @see #getDefaultHttpSolrClient()
   * @see ZkController#getSolrClient()
   * @see Http2SolrClient#requestWithBaseUrl(String, String, SolrRequest)

and that would work? I'll take a looksee at that.

I'm also fine with the PR, TBH... enough callers of it want a SolrClientCache that it'd be annoying to outright remove it. And it's not a big deal if a plugin or something uses it when they could have used an alternative.

so coreContainer.getDefaultHttpSolrClient().requestWithBaseUrl already is used in some places in DistribFileStore. However we do:

final var fileResponse = solrClient.requestWithBaseUrl(baseUrl, null, fileRequest);
        try (final var stream = fileResponse.getResponseStreamIfSuccessful()) {

can't quite figure that getResponseStreamIfSucessful to work yet